Domain-Specific Software Architecture frigineering Process Guidelines ADAGE^M-92-02B Version ... Page 1 of 2 

Domain-Specific Software ArchitecWre Engineering Process Vjew orc j own | oac j. 

, , Guidelines ADAGE-IBM-92-02B Version 2.1 (1993) (Mike oweao.com/dssa/lmdocs/lBM9202.ps 

Corrroiions). (8 citations) Cached: PS : gz PS PDF DjVu. Ima^e Ugdate Help. 
Will Tracz, Lou Coglianese 

ACM SIGSOFT Software Engineering Notes From: oweao.com/dssa/lmdocs/lmdocs (more) 

Homepages: W.Tracz [21 L. Coglianese 

Clt£S0£f H.Q.rafi/S.e.a.rc.h Bookmark Context Related HPSearch (Update Links^ 



^/yvvvJ<.> 1. . . «^.>* SV<*t*< J^V<\W-> 



(Enter summary) Rate this article: 1 2 3 4 5 (best) 

Abstract: "In order to reuse software, there needs to be software to reuse[12]." One of the Comment on this article 

dilemmas that has prevented software developers from reusing software is the lack of software artifacts to use or the existence of 
artifacts that are difficult to integrate. Domain-Specific Software Architectures (DSSAs) have been proposed [7] in order to address 
these issues. A DSSA not only provides a framework for reusable software components to fit into, but captures the design 
rationale and provides for a... (Update) 
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...data within a specified period of time from the occurrence of an event. Application designers often impose these 
implementation constraints^] to satisfy the needs of interfaces with other systems. Any component in the architecture 
may have this requirement imposed. The most... 

.... [HC91] Since then, Domain Analysis has been associated with the development of reusable software components 
[Gom91] HC91] Tra92] TCY93] Some reuse is apparent while other reuse is more difficult to identify. For example, it is 
easy to imagine a collection of reusable... 
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writings can only be found in inaccessible software design documentation. To improve the state of 
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there will be a textual description of the functional requirements that may also describe certain behaviors 
early in software development. Inspections of software design can be especially crucial since design 

wvw.c^.umd,edu/lJbrap//TRs/CS-TR"4353/CS"TR -4353.pdf 

Analysing Software Requirements Specifications for Performance - Dorin Petriu Murray {Cgrrsct) 
Use Case Maps, completion, non-functional requirements 1 Introduction The earliest decisions 
the context of automated model-building from software design products, which may be part of the 

WAV.sce.carSeton.ca/ftp/pub/cimv/petriu-req.pdf 

UsinjgLUML&^^ (Qoirectj. 

Using UML to Reflect Non-Functional Requirements Luiz Marcio Cysneiros Department of 

by the system, and therefore affects the software design. NFRs such as "small learning curve" or 

VAVw.cs.toronto.edu/^cysneiro/articles/Cascon.pdf 

yn|fying.ysej;-Cejilered.a lGon:eo0. 

or tasks flowcharts to supplement the functional requirements analysis. However, for large-scale 

iterative development and manageable software design object models. Ralyte (1999) in the CREWS 

wwwi3d.uu.seHg/UCD2001/Anturies2.pdi : 

Conflicts and Trade-offs between Software.. - Lundberq., {Correal}. 

for 10 weeks. The groups had identical functional requirements. One group (DMO 1) was allowed to use a 
its performance requirements using a certain software design on a certain platform. An equally 

wwvv.ide.hk-r.se/^dha/chapter1,PDF 

A Family of Reading Techniques for OO Design Inspections - Guilherme Travassos Forrest (2000) (Correct} 
activities are concerned with taking the functional requirements and mapping them to a new notation or 
early in software development. Inspections of software design may be especially crucial since design 

vww.cn-umtd.exJu/^ 

Validation of Dynamic Behavior in UML Using Colored Petri Nets - Fettit, IV, Gomaa (Correct) 

a use case model is developed in which the functional requirements of the system are defined in terms of 

of concurrent and real-time object-oriented software designs. 1 Introduction This paper presents an 

www.disUmlgejt/person/Reggi^ 
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Component Indicators for Architecture interaction Assessment - Payton. Davis. Gamble.. (SorrecQ 
properties, protocol information, and non-functional requirements. Together they form an architecture 
of developing a system that fulfills its requirements, functional or otherwise. 2.2 Interface Definition 
conflicts during system 2 design. Software architecture offers a view of the design in 

www .sea L utu isa . ed u/pu bii ca ti o ns/P DG FOG , pd f 

Quality Management Applied to Undergra duate Software.. - Aj Walker Software (1994) (Correci). 

is managed by identifying and elaborating functional requirements, and tracking these through the software 

One of these, entitled Towards defect-free software design provided the catalyst for a research 

www.seai.ac\za/1 994 ...01 /qs1 6331 .pdf 

Streams. Structures. Spaces. Scenarios. Societies.. - Gon<?alves.. .[CarredJ 

of a computation in order to accomplish a functional requirement. Societies comprehend entities and the 
that do not benefit from digital library and software design experience. Wasted e#ort and poor 

csgrad.cs.vt.eduZ-'mgoncalv^'Sso.pdf 

Schemebuilder, A Design Aid For The Conceptual.. - Bracewetl.. (1993) (Correct). 

structured by decomposing the high level functional requirements specification into a nested hierarchy of 

for dynamic simulation supporting embedded software design and development monitoring system 

www-edc.eng.csm.ac.uk/--rhb24/iced93.pdf 

Designing Real-Time Applications with the COMET/UML Method - Gomaa (Correct). 

a use case model is developed in which the functional requirements of the system are defined in terms of 

it is necessary to synthesize an initial software design from the analysis carried out so far. In the 

woodd es . I ntra n et . gr/pa pe rs/g o ma a . pd f 

Requirements. Eypjution {Correct}, 
the RMI calculated for all the software functional requirements. In this case the RMI results to be 
flowed down to the software and hardware requirements. Functional and Operational Requirements. The 
can be split into two broad areas, that of software design and code and the other of verification. Two 

www.dcs . ed , ac, u k/home/mas/d oc/profes200 1 r pdf 

Integrated Process Control and Data Management in.. - Welsh. KalathiL (Correct). 

Detailed Design Support Workflows System Requirements Functional Design Chassis Design Reusable Design 
design processes. Development of systems and software design processes, as well as enhanced supporting 

www,pldworld,con\/Jid[/^ 

The„Common Framew^ {Cprr&cQ 
called Casl for formal specification of functional requirements and modular software design which 
of functional requirements and modular software design which subsumes many previous algebraic 

www.dcs.ed.ac.ufo'horne/dts/pub/\vadt200l.ps 

Fds - A Functional Design Software System - Kirschman. Fade! (Correct). 

design is decomposed into a hierarchy of functional requirements (FRs) which map directly to design 

0 Fds -A Functional Design Software System C.f. Kirschman And G.m. Fadel Center 

1 Fds -A Functional Design Software System C.f. Kirschman And G.m. Fadel Center 

wvw^\vr.ciemsor:.edu/credo/papers/postscript/FDS.pdf 

QSPF„Efficj^ {Correct} 

UCM diagrams were used to capture key functional requirements as sequences of actions and reactions 

5 selected business values and compared to the software design approaches based on manual programming 

www.scexarleton.ca/1tp/pub/UseCaseMaps/sdi01-sales.pdf 

Designing Electronic Voting - Murk (2001) .(CorrecQ 
.15 1.6.1 Functional Requirements .15 

must at least satisfy the following requirements: Functional Requirements System must allow forming 
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that design for such system does not mean^my software design, but also design of th^^ganization and the 
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.CompMngJrpm CQorreci}. 

the application domain are necessary since functional requirements are expressed using technical terms of 
see it. b) Functional &Non-Functional Requirements: Functional requirements include the concepts and 
Engineering p Requirements Engineering p Software Design p ffl Practice: Systems Engineering 

Wv^v.it.dUhdk/'-db/kansai/paper.ps 

Supporting Extension of Components with new Paradigms - Dominick. Ostermann (2000) (Correct), 
concerns, which are independent of the functional requirements of the application, have proved 
Traditional solutions in this area rely on software design patterns and have been successfully employed 

trese.re.utwente^nl/Worksh 

Program RejjaW XCorreci) 

that the software satisfies its specified requirements (Functional testing, 19]Structural testing 

to confirm the correct implementation of the software design (Structural testing [3]and 2) to confirm 

www.crLmcmaster.ca/SERG/papes^s/391.psZ 

Formal Methods in the 21 'st Century: An Assessment of Today -.. - Bjorner (1998) (Correct). 
Requirements: In order to express functional requirements we need clarify the domain, ffl Domain 
tools. 3 Domain /Requirements /Software Software Design: In order to design software we need 
/ Software Software Design: In order to design software we need requirements. Requirements: In order 

wwwjt.dUrdk/-db/]3pan/icse98/lcse98.ps 

stract^ .CQaiiecD 
design of communicating objects to satisfy functional requirements. Success in all these endeavors rests on 
and user interface design on the one hand and software design and development on the other, part of the 
and their consequences for user interface design and software usability. Common narrative styles are 

wwvviomse.com^iles/Papers/structurestyleZ.pdf 

Assessing Optimal Software Architecture Maintainability - Bosch. Bengtsson .(Correct) 

of the software architecture based on the functional requirements specified in the requirement 

requirements. Based on these relations, software design is often performed as an implicit, 

www.cs.rug.nl/~bosch/papere/OptimalSAMaintainabifi 

EyaJualed„Obiect T Orie 

-constraints, given situation, functional requirements, management requirements 
complexity, by Arora et al for the real-time software design in CArora et al 95/and by Lorenz as 

irbx^,tu-berfin.de/*-zuse/gi/dufol95.p55.gz 

Practical Application of Functional and Relational.. - Lawford. McDougall. .. .{Correct}. 

while still permitting the use of functional requirements sped cation and designs descriptions. 

the properties of the design described in the Software Design Description (SDD)comparing them against 

ftp,cs Aiiovva.edu/pLfb/riEs/AMASTpapers/p44.ps 

Controlling Requirements Evolution An Avionics Case Study - Anderson. Felici (2000) .(Correct) 
(i.e.system requirements, software functional requirements, etc.The System Requirements cover 
Requirements Elicitation System Process Software Design Testing Review Coding System Requirements 

www.dcs.ed.ac.uWhorne/mas/doc/sf. safecomp2000.pdf 
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be exhaustively searched allowing critical functional requirements to be validated down to the design 

used to model a complex spacecraft controller. Software design and implementation validation were carried 

seS.gsfcj^asa.gov/WebLMte/sew/l 998/toplcs/Schneider-p.pdf 

Fuzzy Z? - Matthews, al. (1997) {Correct 

to capture the elasticity of soft' functional requirements has been proposed as a technique for 
validation) to a more detailed and concrete software design document. Unlike some of the more informal 

ironb8rk.bendjgoJaiTabe,em^^ 

Fuzzy Concepts and Formal Methods: A Fuzzy Logic Toolkit for Z - Matthews. Swatman (2000) (Co?;o$ci} 
to capture the elasticity of 'soft' functional requirements has been proposed as a technique for 
validation) to a more detailed and concrete software design document. Unlike some of the more informal 

tronbark.bend!goJairabe,^ 

Fuzzy Concepts and Formal Methods: Some Illustrative Examples - Matthews, al. (1999) {Correct), 
heuristically. The concept of a soft functional requirement -one where the degree to which the 
validation) to a more detailed and concrete software design document. Unlike some of the more informal 

jronbark.bendigoJatrobe, edu.au/staff/chrisnV8479 

Architecture-Based Software Engineering - Stafford. Wolf (1999) .(Correct} 

obvious the architecture must satisfy the functional requirements for the system. The extra-functional 
a software system's architecture. To make the software design task tractable, skilled software architects 

ftpxs.colorado.edu/users/aiw/doc/papens/CU-CS--891 --99.ps.gz 

Bujjdjng.^ .(CorrecQ 

well as the limitations of the system. The functional requirements of the prototype are illustrated and an 

technique. The project also reports on the software design issues of the proposed web search engine. 

dis.shef.ac.ufc'mark'cv^ 

Debugging VHDL Designs using Model-Based Reasoning - Wotawa (2000) (Correct). 

others. The specification describes the functional requirements of a digital circuit and can be 3 

design process becomes very similar to the software design process. Moreover, searching for faults in a 

locating and fixing faults within a hardware design or software are rarely available. In this paper we 

www ,d ha \ .tu wi e n . a c. at* staff/wotawa/ai e ngOO . ps .g z 

Component (Coned), 
from the application. Depending on the functional requirements, adding a new software extension to the 
of new solutions for component-based software design and implementation. Component-based 

arnids^ctit.ulwente^nl/pub!icatior:^^/cscw_cbg2000.pdf 

An Object-Oriented Approach To The Co-Design Of.. - Machado, Fernandes.. (Correct). 

are considered, with their additional non-functional requirements that enormously constrict the allowable 

design (hardware engineers)for FMOTSs design (software engineers) and for final solutions design 

shiva.di.timhiho.pt^miguei/PUBLI/mescOO.pdf 

Active Object Oriented Databases in Control Applications - Loborg. Risch. Skold. Tome (1993) £CorreoQ 
subassemblies are placed on a pallet. The functional requirements on the application is that the assembly 
regard to control by software. Typical for the software design problem in control applications are the 

ftpjda.l!u.se/pub/1ate/edsiab/fepo 

Client/Server Architectures for Business Information Systems - A.. - Renzel {Correct}. 

so that my users' functional and non-functional requirements are met? There are several answers to 

requirements. It significantly influences the software design and requires a very careful analysis of the 

st--vwwxs.uiuc.edu/^-hanmer/PLoP"97/Proceedings/renz8i.pdf 
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should be fed by the functional and non-functional requirements and by available design patterns 
software does not meet these goals, sd&m software design &management GmbH Co. KG has been founded 

VAVw4.informal3k.tu-muenchen.de/proj/arcus/TUM-i9 

DECNjS„ArchiMcture (Correci). 

currently available, we split the functional requirements into two sets: those best handled in a 

The paper then identifies the key hardware and software design features, and finally provides a summary of 

gate keeper.dee. eom/pub/DEC/DECNfS^ 

Architectur al Blue prints - The "4+1" View Model of Software.. - Kruchten (1995) (Con^ci). 
handle separately the functional and non functional requirements. Each of the five views is described, 
The rest of the story is in the realm of software design, where, by the way, development may continue 
software architecture, view, object-oriented design, software development process Introduction We all 

plg.uvvaterioo.ca/--migod/746/papers/kruchten-4pius1.|>df 

Momtorin&E^ {Con^ct). 
etc. Nevertheless, depending on the functional requirements, a new software extension to a legacy 
of new solutions for component-based software design and implementation. There are numerous 

amidst.ctit.utwente.nl/publications/prorns2000.pdf 

. System Design - Th ere Are Two .(Corbel) 

He must do so according to a number of functional requirements: the kitchen should be close to the 
Design There are two ways of constructing a software design: One way is to make it so simple that there 

wwwbruegge.irU-urn.de/teachin^ 

Manifest 3D: Framework Develop 3D Graphics Applications - Alfredo Tevseyre Ricardo (Correct), 

(Coarse Fine-Grained Patterns) Functional Requirements Non-Functional Requirements 

names and describes a common problem found in software design and prescribes adequate solution that 

www.exaainicef^edu.arMeyseyre/^ 

Reducing Uncertainty About Common-Mode Failures - Voas, Ghosh. Charron. Kassab (1997) (Correct} 

that different programs have different functional requirements. For example, one program might do a 

been adequately addressed. The staff considers software design errors to be credible common-mode failures 

chacs.nrl. navy.mil/publEcatlons/CHACS/1S37/1997 

Computer Science Environments for Group-Qriented Software.. - Emmerich. Schafer (1996) iGorrectj. 
and concurrently. Section 4 derives functional requirements of a support environment from language 
No. 1996#02 Environments for Group-Oriented Software Design -The Groupie Experience Wolfgang Emmerich 

www.cs.ucl.ac.uk'staffW.Emmerie 
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it is often possible to express the functional requirements as a direct relation between the values 

for safety analyses, test case generation, and software design. We use the ESPRESS notation SZ [1] to 

wvw/fh'st.grnd.da^ 

Where do Software Architectures come from? - Systematic. - Bjarner (1998) (Cou;eei}. 

domain and of functional and non-functional requirements. A major aim &objective of this paper 

requirements. 2.4.1 Functional Requirements Functional requirements "derive" from, or as 

In this paper we show how details of a software design emerges in two steps: software architecture 

www J t . dt u .d k/-d b/jssst/ pa pe v . ps 

Usirig.Pesjgn.Patt^ {Ccfxscti 
including the functional and the non-functional requirements as well as the expectations to the 
Requirements Logical Platform Requirements Functional Design Phase Developer Architecture 
design process. Architecture One aspect of software design is an overall understanding of a specific 

wYW.cit.dWCOT/reports^ 

OjjenVSe^ (Correct). 

alternatives could have met the system non-functional requirements. The final learning objectivewas to 
maintenance and implementation issues in software design. The case study, developed as a classroom 

YAVWxs.emu.edu'afs/cs.cmu.ed^ 

MrfLMhieyjng.^ iCorfgeQ 

aspects such as satisfaction of the user's functional requirements, as well as execution speed, ergonomic 

a team is generally composed only partially of software designers. The head count specific for software 

is . is e . a c , u ki h elsin ki/n v a . pd f 

Finding Mode Invariants in SCR Specifications - Jin (1995) (Correct). 

more than a decade ago to describe the functional requirements of software, the SCR specifications has 
and test cases that are independent of the software design structure. 1 Introduction A software 

fese .gmu.edu/techrep/1 995/95.. 112„off'uft,ps 

Reading Techniques for 00 Design Inspections - Travassos. Shull. Carver. Basiii (1999) {Correcti 
activities are concerned with taking the functional requirements and mapping them to a new notation or 
early in software development. Inspections of software design may be especially crucial since design 

www. csajmd.edu/projecte/Soi^ 

Tools for Design Rationale Documentation in the Development of.. - University {Correct} 

in addition of many functional and non-functional requirements. However, there are always much more 

refine, organise and reuse knowledge for software design. Design Decision Tree is a partial 

w^v.ben-;abs.conVuser/dep/prof/wlcsa1 /finai/savolainen.pdf 

The DECNIS 500/600 Multiprotocol Bridge/Router and Gateway - Bryant. Brash (1993) (Correct). 

currently available, we split the functional requirements into two sets: those best handled in a 

The paper then details the hardware and software design and concludes with a performance summary. 

www.europe.digital.com/info/DTJ907/DTJ907PFPDF 
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. 3 2.2.1 Functional Requirements . 
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The Common Framework Initiative for algebraic specification and.. - Sannella (1999) {Correct}, 
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of functional requirements and modular software design which subsumes many previous algebraic 
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In this paper, we first consider the functional requirements for the control architecture of humanoid 

learning capability should be considered to design software architecture of humanoid robots. 3. A 
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scenario is a means of specifying the functional requirements of a system. An operational scenario is 
-an annotated record of the system and software design decisions and rationale resulting from the 
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I. Reusable Software Catalogues - Design and Retrieval Support - Weber. Casais (Cprreat) 

searches for interfaces that fulfill his functional requirements. He may do this by learning the concepts 

class hierarchy. As in classical modular software design, interfaces must be separated from their 

ftpizi.de/pub/PROST/papers/catalogues.ps.Z 

Uteratyre.Sujve^ .{Corcec& 
B. 1992)Representing and Using Non-Functional Requirements: A Process-Oriented Approach. IEEE 
acquisition methods and the two type of requirements: functional require6 expansive to correct (Boehm, 
M. E.McGowan, C.and Ross, D. T. 1978)Software design using SADT. Structured Analysis and Design, 

frp.crim.ca^gSoo/privee/Hvrabies^vl.cl -SSo-requirements-survey-vl .O.ps.Z 

Appj;y;irKjJ^ .(Correct) 
company requirements, known as design or functional requirement these are generally giobal product 
compared to the functional decomposition of a software design. An overall quality measure for the 
type, function, technology used, method of design, software specifications, the importance of software 

wwwjnformatik;hu-beriin.de^ 

Client/Server Distribution - A Pattern Language - Renzel. Keller (1997) tSoi£sct). 

so that my users' functional and non-functional requirements are met? 1 This work has been published 

requirements. It significantly influences the software design and requires a very careful analysis of the 
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been proposed for formally representing functional requirements, the SCR tabular approach is one of the 

quality of thetoolset' user interface and its software design [4]A high-quality user interface would 
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The Design of Hybrid Systems using the SEA Environment - Rust. Stroop. Tacken (1997) .(Correct^ 
of systems under consideration, not only functional requirements of individual system parts must be 
where the main focus is the view point of software design for embedded systems. Due to the hybrid 
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as refinement of the service description requirements, functional analysis, network requirements 
transforms a high-level design into a detailed software design and develop the necessary software 
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A ModeJ-BasM .(Qsnss). 
with a specification delineating the functional requirements. Figure 2: A typical waveform trace 
design is increasingly getting similar to the software design process, and the search for faults in the 
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Keywords Software architecture, software design, software architecture properties, 
Keywords Software architecture, software design, software architecture properties, collaborative 
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A New Programming Paradigm for Engineering Design Software F. A. Salustri R. D. Venter Department of 
"A New Programming Paradigm for Engineering Design Software, Engineering with Computers, 10, pp. 
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Abstract ,™™,w.inttenned manufacturing (CIM> system 

will doxndoo our arnLty to ^^^^.^^Tt^ dtvetonroent of eoftware '» ^^.ITL which i based on rwo desi 5 n axiom*: 



wftSJcs for top cooiplw sierra mmm f ™jSie, and unmanageable, llic purpose of 
will de«nd oo our »^Jf^^rCo^^^ development of wftware « slow b ^ don ^° ^ 

ion Awor- The artomattc approach is besed on _im rewg ^ proems 

. . • j._«n( tttmna the di 



tills paper n w pro™*; » ~~rr- TZ^e- Awoff- The artomattc approwa i* »»» "L^SS ,-omaia. end the pw«i domairr. ltc ncco map 
the lru*pe*Jen« ^^^^^^^mer domain, the functional domain. ^Pj^^^onil f^u brines, design 
the wistnxx of independent il^ Jr^srSc decomposition of the character** v f^V^nrosir£rc ^ the nc« to wasfy the desi-a 
between vinous domains dups dfiSl £lS L^^^rtqiiimi between the doroayis f« ^W^' acs i gQ in addiiinn to 

S=SssSSSS&&^ 



■-utXlion itni;tu:c 



Keywords: Software Design. Ax ton a. 

Introduction rrTM v - wi M v ^ by industrial firms, the 

As computtr-iniesrttrd ^f^i^^f This is 9 
rcUability and cost of software wM £SSvH taU in the rrtb* of an 

serious issue since ^ enrrent state of ^^^^SXSS,5£ in the form 
art, nc.wuhstaoding significant ^^^^ 5>. Asa 
of SADT YDM (2). Objett-Oremed «i Sw software 

luolt. .he software developmem com is IgjjMUid ""^^dlvelopsd 
mdnicnAncc cos; it several un*s gr=*er ^^^ y ^o^perform'K 

S= 

many functions thai should not be affected. 

rather Am bj, ite hodwai* ««< «■ feSolS nowmiiK software 
nwihooologie. for software <*«»<> "jESy^JSrf <o amplify *e 

engineering can be establishsd. 

b tinew-l tr^woA f« Jf'H'fS^Sf f^vSil 

SfS«ri<lMlsn iLough ik« ippfiewon ot the <tels» « «>™. 

elsewhere. 

Review of the Key Concept uf Axiomatic Design 
The design pnxxM consists Of several «ept 

1) EitablisbJMiii of teijn goals tc satisfy a givto of perceived needs; 

2) ConcepUBliaadon ofdesgn solutions: 

3) Analysis of the proposed solution: 

4) Selection of (he best design from ur^ng those proposed: 

5) Implerneiitation. 

These *cnvices occur between and in different desi^ domains. 

The desbsn domiini ue iUuscwed in Figure 1 . The consumer don^ >|-^^ 

domain where me customer needs «e trinsUtcd m n ^« of f^on^ 
requircmcnw (FRs), which co«*itme * c^ten^^or^T^ ^ 
trapped into the physical domain, where the design paomcicn. (DPs) J« ™» " 
SSSsadsfy theFRs. The DPs id the P^^ w \ n n a "^3^« 
OTOcess domain in tonu of the process vanable* ^PV$) . ^ l «««*5 3 * 
§SS Aep^^ domains are" in the form .ubrout^ <^nrg jy^v 
com?iten iSw forth. Therefore, there can be many 1 ^^.^" th l£«" 
dcZin. depawlint on the number ot* wbrourines. and sub-SUbroudnes. The term 



W U drJIood in trdi VP* u> jepwcfl subdorW PV, in differed ^es 
prwde inputs :o the physit;*l domain. 

desijti process. 

decomposed knd fonr.ca mroaoia ««. . ^ w ^ ^ fact, m 

order m decompose »JKi^»if 13 cSri« * design wluticn vfhicb « 
m0 ve over » ft. Pjg«jJ ^"'J^ ^ ^ w lhe AieMMl ctamio ^ 
6h«^^^i^.??lnSS^m 2. Therefore, lh« concepi.of 

^Sn^ d . pn^d y ^ fc» one level to d—, 

tower levd. 

Axiom. They arc stated " follows; 



TNa went was done ai MiT durinoSanp<5ock Kinta sawattai ywai. 
^nr?a/s of t/itf CtRP. Vol. 40/1/1991 



Ajaam_L 



NSSSebidcSer^ of runctor* rtti^temer.is 
Minimize the information content 



IFRsWAl I^M 



0) 
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Knns of i« iratepcnden. compone no « 1 J« , A) u , 



(2) 



^flKfeKW Axiom, (.fovided that DPI aie changed »n a specif* sequence 
other designs ore coupled design*. 

A similar clarion can be wrinen fo, rnapping becv^n ^ Pineal and the 
domains u: 



(DPst |?Vi] 



(3) 



^ tB3 b . process design matrix ^IPV^t^^ctor 
pwess variables in the process ~^^^^£lv&n chto dugoTil or 

Eq. & to relate |FRs| to (PV$| dirccily. 
process. Information 3 defined as 



613 998 4926 TO 170330D2763 

afmhiW' ^.rrTrin^irri DesomCgajfflfl CR /functional Rcqairtmen;} 

hierarchy to the functional eomain ana a \ r J^T , DPs aie the key UitJUts w 
Fib ait : the ounim^ V «*Jg^ ^farc^is a set of 

relevant domains. 

The dev.gn pn*e» r^s £J^T^ 
between Sc two MerarchicaJ trees *X h ^cMcil ucc juncture. Vr.c 

mapping process begins m± *« oy^" E^E™*, to meet me specified 

PRs witfcout vioianng the ^^^^A^ S t ^heDP (kwiaim When the 
arc performed at each l^clcf ^ri^byK^ s^cf DP*, the FRs 
de*£rt solution cannot be finaUaed c* cr^pl^ oy ^Vf ^vel lowcr , <h c DPi 
X be decomposed fcnhcr Jn dduuof *^ r ^S The Iswlevd FRs 



P. 84/08 



content, i.e.. 



Un =min| i 



(5) 



In any design sit^on. « « PjgWH, y of ^£ ^ 

wishes to achieve tn terms of tolerance oes-gn m*** overlap 
e££e uCdelMai ^^^^^ 

berwws the desigrxr specified »i ^ ab 7 e ti^sa Th^fc«r. in 
"System Range", is the region *r*re the ^S«SbtmhKn is; 

the cue of uniform probability dwnbunon function, Ec. ,4) may t» wnnrn «• 



I* logs |- 



S ystem Range 



\ Common Ranged 



<6) 




$UCfDU*Tes. 

i^femtiident of FRs or other constraints. Sometimes, constraints ?ws^ 
ItejE^S ^donin « 'the product doiriUn to the Pactional domain. 

•iliese concepts viU now be applied to toftwaie design. 

Axiomatic Software System D*sigo 



decomposition process -a» be executed 

& a 5Si'S^U« <fr»> ^ Mftwtre sy5te,n a,e 10 

meet Ac user need* as follows; 

PR, = G=ncra te the DB (call number + keywerc data bast) for new 

FR2 .P^T£&*«*« "Pon^rch m,c^ -ins »«« 
keywords only 

At firs;, n DPI is ^^u^^^n^iaer^M^ni^^^^^ 1 ^^^ 

FIU may be chosen as; 

DPI - Content of ihe bode 
DP2 - Set of subject keywords 

ii a dccoupld design, i-e.. 

iFFEl lxXiDP2l 

us t*j^J3ws. ssssjsawss kiss srs 

decomposed to© FR1 1 and FR12 as 

PR 1 1 - Assign a call number f ID ^ber) to a w book 
SlUoeaeVatc subjcci keywords for the new boo^ 

FRi is timilariy decamposed cs 

manner as explained in -Jm step I . 

OPV t = HeadUne infoxma^ cf the book 0eld. rifle. a*hor, P^li.hex. 

year, esc.) 
DPI 2 » The abstt-ac of the bocrtc 

intern has been used at ^JSjg^lfcSStoi are the key Looms (PPUI « 
The field. bOe, authors ^.^S^S^vffl a number iu a nt* incoming 

FSft does «■ Sed ID be decomposed any funher. 

fumrc search P^^K^ rS fiend** a q^ry with a series of 
the book being ^searched. TJ^r'iSSSd fi^worfi ihicb can p«p«iy 

Step 6 and 7. 



■ iSffiwiu i« design matrix u triangular as 
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I FB11 I JX Oil 
I FR12 Tlx XJl 



OP11 t 
DP12 I 



(8) 



t 

be 



Effecn« D% ^^^1 the FR21 and FR22 may be selected as 

DR1 = Nurr^r of keywords which f^^^Xf .hem 
DP22 = Siring of keywords to find references wmcn conEm. 

To process search query without 

IFR21). the query need tojnclude as mMy subj^ ^^ererTes. which will 
greater number of keywords will result longer li* 01 ^thod of 

iSakc the searcher very amc^onsunaing J£«g«; SStei^SuS. is adopted 

the possibility of missing relevant references. 



Functional Domain 



Physical Domain 




f \o 4 The Zig-zag Decomposition ot the FR and OP Hierarchy 'Sftuaww 
^ S 3d lines sfcJS ^g-zaocing path ^.^^^SpTer^ 
dotted tines indicate the vertical connection .n the Fft and OP hierarchies. 



v , ^ . rt f nP* If the FRs need not be decomposed any funher, they form 
the selected set of DPs. » ^errv. J™ 3 rLr ^j- wnno .i5o n orocess terminates when 

in this paper as a leaf of the FR nee (see Fig. 2). 

A module is defined in t^v^^ffif^^^X 

module. M121 in Rg. 5 transforms the DP121 to the FRIZ I. 

Based on t hi, process of ^P-^»^S«tt^h2 

this stage of design. 

the system integration phase of software design, 
integrates child modules into a parent module. 

mwmwm 

. assess 

Sdtack Action, the program will quickly become unmanageable, 
corresponding to n FR leaves. 



design scluuon* aeo-pled^ 



I FFr21 \J X Xll DP21 \ 
\ FR22 I Ix X A DP22 I 



(9) 



52 FR12 £e., generate keywords for the new book) is decomposed for the 
selected DP12 as 

this is done, the sue of ^* F R12^ ^defined so as to generate 
design solution would become a coupled design. 

may be stated as 

DP121 « Nouns extracted from the abstract, (trivial ones eliminated) 
DP122 =• Synonym dictionary 

For the purpose of the illustration, we will assume the ^^^^J^ 
pTwerful P Xthe keyword dam base can become ""M ^ 
design matrix is diagonal representing an uncoupled design as. 




Rg.5 Module-June*™ Structure Diagram 




SHEDS 



Fig. 6 Modules and the Main Module 



3^- 



(t» 



(0 



FR122. lO xJlDP122f 



(10) 
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ftflffl FlfPrY piayram . . . ; ltnc rion structure diagram can be 

By using the joncdon characteristics, die ^^"^^ S Sr^ w ofdaia stream 
e£ily convened to a network-type ^^^J^V^J^^h has been 
among modules (Fig. 8). This « ^^^^Jf, 0 "^n^^Jysis and design 
the kcV graphical representation in ™™^?JSb?S storting point to tRe 
methods (10). The resuhof ™^ f tf e Sh of which Sen can be 

programmers who can code programs tor eacn muuu.*. 
structured to develop the main module. 



Now Book 




n»a Da* no. Oayam wnier, B aefived Iron. mt Modulo-Junetioo aructur. Diagram 



Design of a Rib Design Software — A Case Study 
The steps involved in "".^.S ™^So^d«t^r 
molding of plastic parts will be described in this secQon. 

Consider the design of a injection ^JS^S^SZ^^^^ 
molded pan is usually designed by an .^ hc ^" c a a ^ n J^J? ™ c moldability 
Sctail^^ the 
of the pan and its rnechatucar v^«U dSS^SupplemeaMiy 
product design and need to be provided by ^^^^^^Vnginecrs to 
features are then added to die P n ^J r h ^ b /J^^ 

molding process. A nb can also play ^ e .° ! n a JT^X slow filling may cause 

»™4 r-Kwi- ftf the. oroceduie for making defect-free parts v?)- ^ $oiw<u^ 
"^tTivll^K^a^st n&d designers to make the pnmary shape 
of a plastic pan moUabte and mechanically sound. 

WSated as the FRs in the functiona. domain. 

The highest level FRs are: 

FR1 = Specify reinforcement rcqmrerneitt 

Slga'SSSSiTSSLe- snucure by simuiadon 
The DPs which make the FRs decoupled are selected as 

DPI « Primary shape of the plastic pan designed by an application engineer 

(cavity side) 
DP2 = Ribbed structure (core side) 
DP3 = Applied loads (expected) 

The design matrix at this level is a triangular matrU which indicates that the design 
solution is decoupled, i.e., 



. . lh * -(Hons where the maximum deflection or 
Depending upon the shape *f SEJSgMr intuitively; for example, 
stress concentration occurs « ^"^J ^Tan. which can be simplified to 
the wide bottom plate or the long »J ^ f fc rimarv gcomcn y can 

elementary geometries. simple smlcnU formulas 

be characterized by a set of '^^B^^? m ?S gU ess for the reinforcing 
for thin plates and beams cM * geometries for the rib 
requirements. In this «se «udy, * hr «^X7lati a circular plate, and a 

applied respectively (18). The selected DPs are: 

DPU ^ Elementary geometries . 
DP 12 = Structural formulas from the nandbooic 

The resulting design matrix becomes a triangular one. 

The FR2 is decomposed as 

FR21 = Generate ribs which do not deteriorate the manufacturability of 
FR22 - GcSe ribs which can meet the reinforcing requirement 

b»»i^ 

control FR21 and FR22 are selected as 

QP21 = Cross-sectional shape of a rib structure 
DP22«* Number of ribs 

. . . »k, poii FR 12. and FR22 can be described by the 

[he FR21 needs to be decomposed further since the DP21 is not sumciem » 
describe it. 

Third Lewi SD ecified so as to assure ejectability. avoid 

3£K5^^3SS^OT. sinkmark which is a local den, 
S onS« opposite to the rib. The FR2I is decomposed as 

FR211 «= Avoid warpagc 
FR212 =» Assure ejectability 
FR213 - Minimize sinkmarks 

Cross-seedonal p^^^S^S^ 

characteristics of mjccDon rnolding.^ f^^Lft w c . The wall thickness and 
the root thickness, the filleung ^S^^ w^tS^ the primary geometry, 

^^Hp^nwek the following DPs are selected. 

DP211- Rib height 
DP212- Draft angle 
DP213 = Root thickness 



However, the design ^^^iS^^t^ ^ ^ 
inarms of tolerances) cannot be satisfied by the process as 



IFR2111 fXO Xl|DP2H\ 

FR212HXXO DP212 
\fR213I Lx X XJ\DP213f 



(12) 



( FR1 

FR2[ 
1FR3I 



\ fXOOl|DP1\ 
U X X O (DP2 
I Lx X XilDP3) 



(ID 



At this level it is recognized thai once the DPI and DP2 are fixed, the FR3 can be 
^y meTby S^e which is a commercially avaUaWe sr^n^^s 
scfcware package. (ANSYS is selected in this case study.) Then the j*R3*jec°mes 
anFR !£f m ftS functional domain and the subroutine constitutes the module. M3. 

The FR1 and the FR2 need to decomposed further since the design solution can not 
be finalized by the selected DPs. 

to C ordVt> V decide whether the xeinforcement is required or not. *e 
pMorn^e^me given primary geometry under certain loading c^dmons must 
teouanrified However, the loading conditions of most plasnc pare are not pre- 
^ccTef explfcWy^t are given 3 such as to avoid cEe ^"e maximum 
Election of L lid plate or the possible stress concentration at >^"£** 
and so forth. Therefore, the use of a complicated toucfcntai LfT^S darl 
complete structural analysis is not an effective method due to the labonous data 
preparation effort and cnonnous computation time. 

The Fill is decomposed as follows; 

FR1 1 = Characterize the structural performance of a primary geometry 

under implicit loading conoiaons 

FP 1? ~ r>.rniat« the Tginfmcement requirement 



injection molding is inherently '^g^^^^^^^ 
solidiQcation of polymer melts M^ ^^'^pled unless the tolerance is 
which can make the design rnatnx unfoupled ^eco^P inc i udc ^g. 
very large. This is an DP and PV 

zaggingnotorfy between the TRand [DP ^°^^^; facturab aity issues. One 
domains in order to meet the ^ h }^}^^ ^ 1C imc) is ie use of the 
way of handling this kind lof P^^^f^^^owicdgc of dcterrnining the 
knowledge-based system. The^r^aamts and expert ^eoge^ ^ ^ 
cross-sectionai pamrtyters between U* DPs ^ C ^X expen system module. 

generate acceptable cross- sectional geometries of nbs. 

Module* Junction Stroctur* hierarchical structures of FRs and DPs art 

Asai^ttftteog-agdW nodc s are formed 

constructed as the part ^^^^^R^^c for each FR leaf can 
when the FRs can be satisfied by lhe fl «^ s D a f^ s ^ branch are not coupled, 
be generated indepcndenUy as long » f*s * ™^ { ^ e rib design soflW are 

A more detail rcnon of the development of a rib design software is given by one of 
the authors elsewhere 19). 
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^ FR tro"*"! 




V 



\U2\ j | M» 






[MZ11 | | K212 || U2U| 



from the 
PV 

-domain 



Fig. 9 The MooWvJuncticn Structure Diagram for me Rib Design Software 



Axiomatic Design Method v.s. Structured Design Methods 

often lack rigor in specifying requirements of complex systems (14). 

Sntt£Sw£*£ «o Vision makingin rcqu^M^^^ ^ ^ 
cnecification whereas Yordon Design Methodology (lo), Jacxson ^"HS" 
Si™daTflow diagrams, enriry-relationship diagrams, and smtciure charts. 
Structured analysis methods use a top-down d«omF«sidon me&od to 

& (CT^cffiSSiques have sirnflar underlying concepts whKh may 
be stated as follows (14): 

- Top-down, hierarchical structuring 

■ Divide and conquer , 

- Graphic communication and documentation tools . , dccision 
However *e structured analysis and ^Z^^SSS^^L 

Sr^ co^ie essential in dealing with complex problems. 

SADT (1) has been one of the well known structured .analysis and ^tetan 
meSitologies. The SA box is the basic idea-entity «P*^S ™** f 
f^rZSl* 5 the SA box mean input, output, control, and mechanism as shownin 

tSZSL » to module which must be handled in the process donuun. The 



input via control 
junction (from 
upstream modules) 



•control" input ^^^J^^^g^M* 
decoded ^J^Z^Z^M^ aVthe high level of the FR 
satisfies the independence axiom, ™7 ™-~iiiTe_ That is the design process 
hierarchy ^P^^^^X^^ec^p^oon pmc.cds funher. 
will become more and ™= ^ ^ t Sv% bT™ since it docs no. have 

design. 

sasi^r^sSSSaSSw^t 

referent (i.e., design axioms for the gnftews ana ^ y cUminat c poor 
provides design evaluation emenj which ^tej« ™g2rt for new ioeas, 

S^^mel^of sr^crurl^erarchy, not only in the funcnonai domam 
but also in the physical and process domains (8). 

An Ideal Software System 

For this ouroose consider a functional requiiement hierarchy, where the lowest 

upper level FRs can be constructed by means of FR^s. men. we cm «, 
software module data base as follows: 



input 



SABox 



output 



mechanism 



(a) 




junction (from 
downstream 
modules) 



Ro.10 Comparison of the SADT and Axiomatic ^^ i ^ ra Des ^ 
(a) Structural Analysis Box (b) Module-Junction Structure 



frV-m(dp\. dp*, dp!..... dp? J 

FRk-M(OPi DPiDPi...-DPT.) 



FRk-M(OP\. DPI DP 3 ,.-.. - DPS) 



(U) 



Equations (12) are a library of softwares (i.e.. data base). For ^examp^ J tat 
equation for f^V states that any one of the modules (e.g.. »• ^ 

ex.) in the database can be used to conuol ^V- Similarly, any one of the can 
satisfy FR*. 

Vow suppose we need to develop a software for a problem consisting of the 
following three leaf FRs: H*. I* . The best software package is the one 
thai consists of DPs which affect only one of the FR4- This can be expressed as 




(13) 

design which satisfies the Independence Axiom. 

w?ic h r^^^ 

a DP that can yield FRV. it can be anything in the data base; for example.^ , 
However, when we then look for the software module that can yield ™> after 
selecting DP? 5 , we must look for a that does not affect F*. Finally, when 
we look for a DP, that can satisfy ™± after ™\ and ™3 are taken care of, there 
are now two conditions: the DP» in the data base that can satisfy the Independence 
Axiom is the one that does not affect both ™\ and FR, . Then, the design equation 
for the decoupled software package can be written as: 



J™lU? x O (DPT 
I? ? xJ\DPi*J 



SB 



(14) 



The Question marks indicate that even if the design elements indicated by (?) are not 
^n^^re ^l execute the computation as long as ite modules are 
computed in the sequence indicated, i.e.. D* 5 first, then . and finally 
followed by DP| 8 . Such a program will involve many control junctions shown in 
Fig. 7. 

software packages. 

The key to the creation of an idealized software package is the creation of the 
complete data (i.e., module) base. 

In many situations, the data base is so extensive that we may be able to find another 
c.r «f HP* which satisfv FRi. FRlf* FR * independently. Then, the question 
wh i C ; h s e t\s S Ser solution for the given set of functional requirements. 
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[181 
(191 



ln order to decide which is a better solution , we^ve ^^^t 
A^om. FRW may have ^'f 111 !"^^^ 0 ^^^^^^^!!! degrees of accuracy, 
software modules may yield the results for FK ^ won au fa prL^ The best 

Therefore, the information ^ c "" ""^^ wiSi the minimum information 
solution, according to the second Axiom, is the one wiui 
content. 

Summary 

characterized in terms of following: 

n ^ .oftware design begin, with the speciftcadon of FR, from the perceived 

needs of the user. 

; 2)A ^ap^.recogrdxes,he«^^ 
< spaces in software design. 

3) The design process requires mapping between dim domains. 

*) There are two design axiorr* tl*r must besadsfied by the mapping process tn 

orderTo develop an acceptable software system. 

5) Each domain has a characteiisjic . vee ™J[^ , ^^5'J ; J n 5^^ 1 S?W t ne^i"' m " 

C The decomposition process requires dragging between the two adjacent 

domains. 

8) Each FR leaf has one module of software which is the design mam, between 

the FR leaf and the selected DPs. 

s^^^fflsa?-"* — con,ro1 m 

feedback junctions. 
Tt*a*orna*:desi^^ 

software systems. £ ^^I^^^T^Snl De^nMachine as a tool 
for software development. The ^g^JST thesf trame, criteria, and 
for software development is established t>asea on u 

methodologies. 
Dedication 

One of the authors of this P^^i^^e^ r^achSe*. SpS**?^ 
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